Errata exists for this version of the document.

OPC UA Applications represent software or devices that provide information to other OPC UA Applications or consume information from other OPC UA Applications.

This Annex contrasts the Subscription functionality available in the Client Server communication model with the data distribution mechanism of PubSub. See OPC 10000-1 for an overview of the complete functionality available with the Client Server model.

In the Client Server communication model the application exposing information consisting of physical and software objects is the OPC UA Server and the application operating upon this information is the OPC UA Client.

The information provided by an OPC UA Server is organized in the Server Address Space. Services like Read, Write and Browse are available with a request/response pattern used by OPC UA Clients to access information provided by an OPC UA Server.

Every Client creates individual Sessions, Subscriptions and MonitoredItems which are not shared with other Clients. I.e., the data that is published only goes to the Client that created the Subscription.

Sessions are used to manage the communication relationship between Client and Server. MonitoredItems represent the settings used to subscribe for Events and Variable Value data changes from the OPC UA Server Address Space. MonitoredItems are grouped in Subscriptions.

The entities used by OPC UA Clients to subscribe to information from an OPC UA Server are illustrated in Figure B.46.

Figure B.46 – Subscriptions in OPC UA Client Server Model

In this model the Client is the active entity. It chooses what Nodes of the Server AddressSpace and what Services to use. Subscriptions are created or deleted on the fly. The published data only goes to the Client that created a Subscription.

The Client Server Subscription model provides reliable delivery using buffering, acknowledgements, and retransmissions. This requires resources in the Server for each connected Client.

Resource-constrained Servers limit the number of parallel Client connections, Subscriptions, and MonitoredItems. Similar limitations can also occur in the Client. Clients that continuously need data from a larger number of Servers also consume significant resources.

With PubSub,  OPC UA Applications do not directly exchange requests and responses. Instead, Publishers send messages to a Message Oriented Middleware, without knowledge of what, if any, Subscribers there may be. Similarly, Subscribers express interest in specific types of data, and process messages that contain this data, without knowledge of what Publishers there are.

Figure B.47 illustrates that Publishers and Subscribers only interact with the Message Oriented Middleware which provides the means to forward the data to one or more receivers.

Figure B.47 – Publish Subscribe Model Overview

PubSub is used to communicate messages between different system components without these components having to know each other’s identity.

A Publisher is pre-configured with what data to send. There is no connection establishment between Publisher and Subscriber.

The identity of the Subscribers and the forwarding of published data to the Subscribers is the responsibility of the Message Oriented Middleware. The Publisher does not know or even care if there is one or many Subscribers. Effort and resource requirements for the Publisher are predictable and do not depend on the number of Subscribers.

PubSub and Client Server are both based on the OPC UA Information Model. PubSub therefore can easily be integrated into OPC UA Servers and OPC UA Clients. Quite typically, a Publisher will be an OPC UA Server (the owner of information) and a Subscriber is often an OPC UA Client. Above all, the PubSub Information Model for configuration (see 6.2.2) promotes the configuration of Publishers and Subscribers using the OPC UA Client Server model.

Nevertheless, the PubSub communication does not require such a role dependency. I.e., OPC UA Clients can be Publishers and OPC UA Servers can be Subscribers. In fact, there is no necessity for Publishers or Subscribers to be either an OPC UA Server or an OPC UA Client to participate in PubSub communications.

_________